Skip to content

RFC: Add basic support for local and remote CAN #1719

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
stoupa-cz wants to merge 5 commits into
base: stable-25.0
Choose a base branch
from
Open

RFC: Add basic support for local and remote CAN #1719

stoupa-cz wants to merge 5 commits into from
+425 −2

Conversation

@stoupa-cz
Copy link

@stoupa-cz stoupa-cz commented Aug 27, 2025 •
edited
Loading

Description

This is a draft of basic CAN support. It is in RFC, as there are open questions, missing docs and tests, and moreover, it needs more testing. We plan to use it to remotely access the satellite's telemetry buses during development. It is tested on our local branch to remotely access the satellite's telemetry buses during development.

Local and remote CAN resources are added. Additionally, a simple CAN driver is added. The driver has very limited capabilities. For local use, it can set up the interface and tell you the interface name. For remote use, it establishes a transparent tunnel using cannelloni. With it, you can use the local virtual CAN interface. All the traffic is routed to the real interface on the other end.

Be aware, as cannelloni states in its doc:

cannelloni is not suited for production deployments. Use it only in environments where packet loss is tolerable. There is no guarantee that CAN frames will reach their destination at all and/or in the right order.

I tested in the lab only. We will test it in production during September/October.

Draft version (without labgrid-can-interface) is being tested in production for ~two months.

I see the main blocker: it requires root privileges on both sides (exporter and client; even for local use). What is the preferred way to handle privileged access? May we use labgrid-raw-interface? Helper labgrid-can-interface has been added.

Checklist

  • Solve the need for root privileges
  • Test initial implementation
  • More robust handling of cannelloni processes
  • Fix remaining TODOs in the code
  • Rebase on master
  • Documentation
    • The arguments and description in doc/configuration.rst have been updated
    • Add a section on how to use the feature to doc/usage.rst
    • Man pages have been regenerated
  • Write tests
  • Test in production

Reference issues: #1287 and #1289

This is a part of my work at VZLU AEROSPACE.

@hundeboll
Copy link
Contributor

hundeboll commented Dec 11, 2025

Hi @stoupa-cz

Thanks for working on this. I've been experimenting with [socketcand](https://github.com/linux-can/socketcand). It has the same limitation as cannelloni (root on both ends for vcan setup), but the protocol is pretty simple, so the client side can be implemented as python functions in the labgrid driver. This should be enough for tests with limited CAN traffic.

@stoupa-cz
Copy link
Author

stoupa-cz commented Dec 11, 2025

Hi @stoupa-cz

Thanks for working on this. I've been experimenting with [socketcand](https://github.com/linux-can/socketcand). It has the same limitation as cannelloni (root on both ends for vcan setup), but the protocol is pretty simple, so the client side can be implemented as python functions in the labgrid driver. This should be enough for tests with limited CAN traffic.

Hi @hundeboll ,

Thanks a lot for the information. This is a clever way. We are using the cannelloni. Root privileges are manageable on exporters; however, handling them on clients (e.g., developers' computers) is cumbersome.

I'm currently trying a helper like labgrid-raw-interface. I will push it when ready.

Anyway, as pointed out in #1289, we may support both backends (you can see that issue for more information about SW selection).

BTW, is your experiment available anywhere?

@hundeboll
Copy link
Contributor

hundeboll commented Dec 12, 2025 •
edited
Loading

Hi @stoupa-cz
Thanks for working on this. I've been experimenting with [socketcand](https://github.com/linux-can/socketcand). It has the same limitation as cannelloni (root on both ends for vcan setup), but the protocol is pretty simple, so the client side can be implemented as python functions in the labgrid driver. This should be enough for tests with limited CAN traffic.

Hi @hundeboll ,

Thanks a lot for the information. This is a clever way. We are using the cannelloni. Root privileges are manageable on exporters; however, handling them on clients (e.g., developers' computers) is cumbersome.

I'm currently trying a helper like labgrid-raw-interface. I will push it when ready.

I see. I think the cannelloni protocol would be just as easy to implement in python though.

Just like you've done, my plan was to create a resource similar to SerialPortExport, which would start socketcand on a NetworkInterface resource (i.e. can0).

The driver could then connect to the resource similar to SerialDriver. Or do regular socket operations on local interfaces instead of socketcand procotol communication. This still doesn't solve the root requirement for configuration of local interfaces, but as a start we could leave that to the administrator (e.g. using systemd.network(5) configuration).

Anyway, as pointed out in #1289, we may support both backends (you can see that issue for more information about SW selection).

BTW, is your experiment available anywhere?

It still resides in our internal repository, but I've attached it here. It uses SSH forward to talk with socketcand on the target though, as it is just used for communicating with a CAN based service in our bootstrap rootfs, but that's easy to change.

@hundeboll
Copy link
Contributor

hundeboll commented Dec 15, 2025

Hi @stoupa-cz

I tried running an exporter with your PR, where a USBCANPort is exported as an NetworkCANPort. On the client, I implemented the cannelloni protocol in the driver (can.py).

It works quite well for our purpose.

One thing I miss from socketcand is the ability to subscribe to certain CAN IDs, so I added (very) simple filtering in the driver.

And again: It might make sense to remove the interface configuration, and leave that to e.g. systemd-networkd?

@stoupa-cz
helpers/labgrid-can-interface: introduce CAN interface helper
e3f3f47 
The helper focuses on the CAN interface. All actions (except `add`) may
be run only on interfaces of type CAN.

It is heavily inspired by `labgrid-raw-interface`. Two subcommands are
currently supported. The `ip` subcommand manages the interface, while
the `tc` subcommand throttles the interface according to the Cannelloni
documentation.

TODO: documentation

Signed-off-by: Tomas Novotny <tomas@novotny.cz>
@stoupa-cz
resource/udev: filter CAN devices in the network interfaces
0ddf303 
The CAN devices are matched in the network interfaces. The CAN device is
not a typical network interface, so filter it. A new resource, CANPort,
will be introduced to cover the CAN devices.

Signed-off-by: Tomas Novotny <tomas@novotny.cz>
@stoupa-cz
resource: add support for CAN connected locally
2604799 
Add a simple CAN resource. It may be used to determine the interface
name by udev matching.

Signed-off-by: Tomas Novotny <tomas@novotny.cz>
@stoupa-cz
add NetworkCANPort resource and export
5b9e240 
Add an exporter part for the remotely accessible CAN. As discussed, the
cannelloni is used as the underlying tunnel.

According to the cannelloni documentation, it should be used only in
environments where packet loss is tolerable. There is no guarantee that
CAN frames will reach their destination at all and/or in the right
order.

Signed-off-by: Tomas Novotny <tomas@novotny.cz>
@stoupa-cz
driver: add CAN driver
fd745c8 
The driver can connect to both local and remote CAN ports. For local
ports, it sets up the interface. The driver is also helpful for
identifying the interface name using udev. For remote ports, it creates
a local vcan interface and establishes a connection to the exported
resource through cannelloni.

According to the cannelloni documentation, the speed of the network
interface is limited by tc to prevent packet losses.

XXX: See the code (a few things to fix).

Signed-off-by: Tomas Novotny <tomas@novotny.cz>
@stoupa-cz
Copy link
Author

stoupa-cz commented Dec 17, 2025

I tried running an exporter with your PR, where a USBCANPort is exported as an NetworkCANPort. On the client, I implemented the cannelloni protocol in the driver (can.py).

It works quite well for our purpose.

One thing I miss from socketcand is the ability to subscribe to certain CAN IDs, so I added (very) simple filtering in the driver.

It seems we have different needs. For us, a client-side "real" vcan interface is necessary. Fortunately, we have a configurable driver, so any client (e.g., your cannelloni protocol reimplementation) can be selected. For the sake of simplicity, I’d prefer to continue using the "native" cannelloni approach.

BTW, what is your use case? Do you want to replay some traffic?

And again: It might make sense to remove the interface configuration, and leave that to e.g. systemd-networkd?

On exporter side, the interface is controlled (e.g., down, set-bitrate, up) when the place is acquired. The bitrate configuration comes from the expoter configuration. It is similar on client when the driver is activated, although the bitrate is loaded from the exporter's configuration. Which interface configuration managed by systemd-networkd are you referring to?

@stoupa-cz stoupa-cz marked this pull request as ready for review December 17, 2025 14:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@stoupa-cz @hundeboll